home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-3154 / 524.txt < prev    next >
Text File  |  1992-05-11  |  25KB  |  630 lines
  1. Info-Atari16 Digest         Thu,  3 Oct 91       Volume 91 : Issue 524
  2.  
  3. Today's Topics:
  4.                Atari 1040STf with hard drives for sale
  5.                              C on the ST
  6.                        GhostScript and all that
  7.             Good places to anon-ftp atari-pd-software from
  8.                   lharc 2.01e vs zoo 2.1: some tests
  9.                            lharc source...
  10.                     lharc vs. zoo (my correction)
  11.                      lharc vs zoo (my correction)
  12.                            Mega2 questions
  13.                         Questions on PC-Speed
  14.                     SIM CITY - STe Compatible????
  15.                          SST for 1040STe's ??
  16.                               STE simms
  17.               Using gcc/g++ to cross compile for the ST
  18.                              ZOOSHELL 0.6
  19.  
  20. Welcome to the Info-Atari16 Digest.  The configuration for the automatic
  21. cross-posting to/from Usenet is getting closer, but still getting thrashed
  22. out.  Please send notifications about broken digests or bogus messages
  23. to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
  24.  
  25. Please send requests for un/subscription and other administrivia to
  26. Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
  27. instead of the moderators are likely to be lost or ignored.
  28.  
  29. If you want to unsubscribe, and you're receiving the digest indirectly
  30. from someplace (usually a BITNET host) that redistributes it, please
  31. contact the redistributor, not us.
  32. ----------------------------------------------------------------------
  33.  
  34. Date: 2 Oct 91 23:04:11 GMT
  35. From: noao!asuvax!cs.utexas.edu!milano!cactus.org!covert@arizona.edu (Richard
  36.  Covert)
  37. Subject: Atari 1040STf with hard drives for sale
  38. To: Info-Atari16@naucse.cse.nau.edu
  39.  
  40. FOR SALE:
  41.  
  42. 1040STf with 2.5 megs RAM, dual TOS 1.0/1.4
  43. Atari SM124 monochrome monitor
  44. Tweety board (not installed)
  45. IMG SCAN scanner
  46.  
  47. Asking $550 for the computer system.
  48.  
  49. Also two hard drive systems:
  50.  
  51. Atari MegaFile 30   $300.00   30 megabyte hard drive
  52.  
  53. TOADFILE 85         $600.00   85 megabyte hard drive. Room for a
  54.                               second 85 meg drive in cabinet.
  55.  
  56. 130 megabyte home built hard drive. This is kinda upgly as the original
  57. power supply burned out and I replaced it with a larger power supply
  58. that wouldn't fit in the cabinet. So, I have the two Seagate 65 meg
  59. drives with the ICD host adapter and the power supply sitting in an
  60. open cabinet. Asking $500 for this one.
  61.  
  62.  
  63. Also, Panasonic KXP4450 laser printer with 1.5 megs RAM, dual paper trays,
  64. 11 pages per minute printout (heavy duty office quality laser printer)
  65. $1000.00 (you pay shipping). The KXP4450 is cheap to use as the toner
  66. kit only costs about $45 from any office supply store. I use Hurrican
  67. Office here in Austin.
  68.  
  69. I have some software I might be talked into including as well, just
  70. ask.
  71.  
  72. --
  73. Richard E. Covert                 covert@cactus.org
  74. CACTUS                  ..!cs.utexas.edu!cactus.org!covert
  75.  
  76. ------------------------------
  77.  
  78. Date: 2 Oct 91 23:27:35 GMT
  79. From:
  80.  noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc
  81.  .edu!unmvax!uokmax!kllove@arizona.edu (Kenneth L Love)
  82. Subject: C on the ST
  83. To: Info-Atari16@naucse.cse.nau.edu
  84.  
  85. Okay, I've posted this question before, but I lost my reply file.
  86.  
  87. I'm looking to get C for my Mega 2, but I need something that can
  88. be used from a floppy based system (I have to DS/DD drives).
  89.  
  90. Is Sozobon any good?  Will it work with the above condition?
  91.  
  92. I bought called 'A Book on C' by ??? and Ira Pohl.  It seems to have
  93. quite a good discussion on C (for IBM/Unix systems :( ), but I couldn't
  94. find anything about how to check the mouse or anything about graphics.
  95.  
  96. Is there an Atari specific book that talks about this?
  97.  
  98. Oh yeah, I want to convert a BASIC program to C, but I need to know how
  99. to do PEEKs and POKEs in C.
  100.  
  101. I'm not sure what the ST Basic command "vdisys(1)" does, but I gather
  102. it has something to do with the mouse (based on the context of the
  103. program).  What the "chain" command is and how it works would also be
  104. nice to know.
  105.  
  106. Please respond by e-mail as I don't keep up with this newsgroup on a
  107. regular basis (messages are gone in 2 days around here and I read
  108. r.g.frp, r.a.startrek, and r.a.drwho before this one).
  109.  
  110.                                         Thanks in advance,
  111.                                         Kenneth Love
  112.  
  113. ------------------------------
  114.  
  115. Date: Thu, 3 Oct 91 15:51:35 WET DST
  116. From: "Ian McCall (Scorpion)" <csd015@central1.lancaster.ac.uk>
  117. Subject: GhostScript and all that
  118. To: Info-Atari16@naucse.cse.nau.edu
  119.  
  120. I've been hearing quite a bit about GhostScript recently, and it sounds
  121. very interesting. But it's part of GNU or something, isn't it? Could
  122. somebody post up exactly what I'd need to do, from scratch, to get a
  123. working version of GhostScript?
  124.  
  125. Also, I now own a Mac LC as my main machine, but I've heard you can get
  126. GNU for the Mac too. Is GhostScript around for that, and if so, would I
  127. just follow the same procedure with Macintosh versions of the files as I
  128. would for setting up the ST version?
  129.  
  130.  
  131. Thanks in advance,
  132.                         Ian McCall (csd015@uk.ac.lancs.cent1)
  133.  
  134. ------------------------------
  135.  
  136. Date: 2 Oct 91 15:27:27 GMT
  137.  
  138. ------------------------------
  139.  
  140. Date: 2 Oct 91 18:36:52 GMT
  141. From: garfield!odie.cs.mun.ca!david10@uunet.uu.net (David Churchill)
  142. Subject: lharc 2.01e vs zoo 2.1: some tests
  143. To: Info-Atari16@naucse.cse.nau.edu
  144.  
  145. In article <1991Oct02.023218.28662@infoserver.th-darmstadt.de>
  146.  DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes:
  147. >Following the discussion I tried three archiver programs
  148. >to backup 151 files worth 700KB of data. The data consisted
  149. >almost entirely of documentation (ASCII) and C source.
  150. >
  151. >Machinery: ST-1MB w/40MB ST-251-1
  152. >I did NOT clean my partition for this test, why should I? I
  153. >never evacuate any partition just for arcing things up. So
  154. >I think this is more true to life, than any more 'scientific'
  155. >setup. I did the test twice, which didn't change any of
  156. >the timing values significantly and gave every program
  157. >a 'fair' chance on a equally fragmented harddisk. Fragmentation
  158. >is more of an issue when unpacking anyway.
  159.  
  160. Fair enough.
  161.  
  162. >
  163. >Results:
  164. >
  165. >ARC 6.02
  166. >   Size: 304048 bytes   Time: 3:48
  167. >
  168. >ZOO 2.1
  169. >   Size: 307207 bytes   Time: 4:45
  170. >after issueing a pack command for an additional 2:20
  171. >   Size: 307151 bytes
  172.           ~~~~~~
  173.  
  174. Hmmm, something fishy here . . . zoo 2.1, using the high compression scheme,
  175. should be closer to LHARC than this.
  176.  
  177. >
  178. >LHARC 2.01d
  179. >   Size: 218964 bytes   Time: 6:13
  180. >
  181. >(my) conclusions:
  182. > So guess what, good old ARC is by far the fastest,
  183. > LHARC is the tightest,
  184. > And ZOO well the -um- most compatible...
  185. >
  186. >
  187. >And they way I called them (thru make)
  188. >
  189. >#ARC=arc
  190. ># update
  191. >#UPDATE=u
  192. ># update with subdirectories
  193. >#DIRUP=uz
  194. >
  195. >#ARC=zoo
  196. ># update
  197. >#UPDATE=aun:
  198.          ~~~
  199.  
  200. Yup, this is a zoo 2.01 compatible archive, not a 2.1 archive. To use the
  201. high compression method, the command line should be 'ahun', not 'aun'.
  202.  
  203. ># update with subdirectories
  204. >#DIRUP=aun//
  205.  
  206. Ditto for here.
  207.  
  208. >
  209. >ARC=lharc
  210. ># update
  211. >UPDATE=u -s -wf:\tmp
  212. ># update with subdirectories
  213. >DIRUP=u -r2 -p -s -wf:\tmp
  214. >
  215. >GSOURCES=*.h *.c *.tlk *.s *.y make*.* memo
  216. >
  217. >backup:
  218. >       $(ARC) $(DIRUP)  arc\backup support doc lib header demo
  219. >       $(ARC) $(UPDATE) arc\backup $(GSOURCES)
  220.  
  221. It's a good test (in a real-world sense), but to be fair to Zoo 2.1, it can
  222. compress files MUCH better than what this test has shown, along with being
  223. more compatible across platforms.
  224.  
  225. >   Nat!
  226.  
  227. Later,
  228. Dave C
  229.  
  230. --
  231. Dave Churchill  DoD #266             * * *      CS Undergrad (Class of '92)
  232. david10@garfield.cs.mun.ca           * * *      Memorial University of
  233. ar473@freenet.cleveland.edu          * * *      Newfoundland.
  234. My opinion is just that - mine!    *   *   *    St. John's, NFLD  Canada
  235.  
  236. ------------------------------
  237.  
  238. Date: 2 Oct 91 22:53:13 GMT
  239. From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
  240. Subject: lharc source...
  241. To: Info-Atari16@naucse.cse.nau.edu
  242.  
  243. since i have received numerous requests for lharc 2.01e source in
  244. anticipation of actually getting it, let me try and put an end to
  245. these requests.
  246.  
  247. i have just received the source from thomas (infinite thanx, that
  248. wasn't so hard now was it?). however, i also agreed that i would NOT
  249. distribute this source, or any derivative source and i will abide
  250. by that agreement. please don't bother asking me. i cannot and will
  251. not post it or mail it or in any other way distribute it. i will ignore
  252. all requests for same. i gave my word.
  253.  
  254. with that in mind, however, when/if i have time, i do intend to
  255. return this particular version BACK to 100% C, in fact 100% portable
  256. ANSI/POSIX (32-bit int) C. i will focus on the portions of the code
  257. in assembler, returning them to C. i will profile the code (even
  258. vectorize it!) and optimize the C performance as much as i care to
  259. so that i will be satisfied with its performance. i will also fix
  260. the bugs in it. this will not happen for several months. after that,
  261. i will return this portable version to thomas for his own use. if he
  262. chooses to release it, he can. if he chooses to continue that work,
  263. i will applaud him. if he moves it to /dev/null, that is fine, too.
  264.  
  265. oh, and i'll go further: i will not post/mail/etc a BINARY ST version
  266. either which would be as bad (actually worse). i might be persuaded,
  267. however to distribute a convex executable image, if anyone out there
  268. has a convex :-).
  269.  
  270. so, i guess i am happier now about the lharc situation. TQ's version
  271. does seem to be the best version on the ST. and i will eventually
  272. (finally) have a unix version to boot. henceforth, i shall retire
  273. from most all public discussions on portability of archive formats.
  274. i still don't think i can recommend lharc as a universal archiver,
  275. but at least i have done something for myself to remedy some of the
  276. problems i have with it. i still think at this point in time, zoo
  277. is about the best overall archiving system available across the board
  278. (i.e. independent of platform). a close second would be compressed
  279. tar files, i think. then arc, and then possibly lharc. lharc _could_
  280. rise to the top of my short list by having all lharc developers get
  281. together and decide on a standard. i just don't ever see that happening.
  282. i think someone mentioned that the amiga version also uses the lh4
  283. format, which i am not sure 2.01e supports. so some amiga .lzh files
  284. would not be extractable on an st. of course, at some future time, there
  285. will probably be an new lh* format. then i am again back to bitching...
  286.  
  287. thank you all for your support during this effort. now we can proceed
  288. with other issues :-)
  289.  
  290. -bill
  291. rosenkra@convex.com
  292. --
  293. Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
  294. Convex Computer Corp.      |ARPA: rosenkra@convex.com
  295.  
  296. ------------------------------
  297.  
  298. Date: 3 Oct 91 14:59:11 GMT
  299. From:
  300.  europa.asd.contel.com!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!mailgzrz!
  301.  opal!unido!mcsun!news.funet.fi!sunic!chalmers.se!dtek.chalmers.se!dxper@uunet.u
  302.  u.net (Per Anders Olausson)
  303. Subject: lharc vs. zoo (my correction)
  304. To: Info-Atari16@naucse.cse.nau.edu
  305.  
  306. DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes:
  307.  
  308.  
  309. >As two people have pointed out I lost 'cause I oversaw the 'h' option
  310. >on Zoo 2.1. I ran the tests again and sure enough the results of ZOO
  311. >came very close to Lharc. Which makes conclusion wise ZOO as good
  312. >as Lharc really.
  313.  
  314.   I found when using ZOO V2.1 from my backup program (which can use any
  315.   compression utility) that ZOO V2.1 still wasn't completely error free.
  316.  
  317.   Unfourtunately I don't remember what the implications were, but since then
  318.   I use LHarc. Both ZOO and LHarc are the only, known to me, which accepts
  319.   hidden and system files so for me that's the only choice.
  320.  
  321.   Also note that the earlier LHarc V2.01? versions quite a lot of bugs which
  322.   could trash compressed data.
  323.  
  324.   pao
  325.  
  326. --
  327. .............................Andrew Olausson................................
  328. ............................Systems Architect...............................
  329. ..........................dxper@dtek.chalmers.se............................
  330. ..............................pao@proxxi.se.................................
  331.  
  332. ------------------------------
  333.  
  334. Date: 3 Oct 91 22:53:34 GMT
  335. From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
  336. Subject: lharc vs zoo (my correction)
  337. To: Info-Atari16@naucse.cse.nau.edu
  338.  
  339. In article <1991Oct03.183321.13105@infoserver.th-darmstadt.de>
  340.  DE7B@br1.hrz.th-darmstadt.de (WALLMANN, GEORG) writes:
  341. >I/O. The cleverer the buffering strategies and the less i/o done (in
  342.           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  343. >most cases) the better. If you just do I/O on ideal devices (clean RAMdisk),
  344. >you are punishing programs who use more clever i/o in order to circumvent
  345. >the ususal everyday pitfalls.
  346.  
  347. yes. agreed. and i did eliminate this from the test as well, tho not for
  348. the reasons that people thought ("he hates lharc so he wants to make sure
  349. zoo wins"). you are correct that a comprehensive test would have sought out
  350. these strategies as a desirable trait. i did mention this in the original
  351. post as well. my hypothesis going into the test was that both were going
  352. to be pretty equal on all fronts. my evidence was that zoo was compiled
  353. with GNU C by someone whose previous (excellent) work i was familiar and
  354. that lharc was well tuned by conversion to assembler.
  355.  
  356. to be fair to me, however, and those with similar situations, i generally
  357. either extract a new archive into a ramdisk to "check it out" or when
  358. creating an archive of something on hard disk i write to an archive file
  359. in ramdisk. in both cases, which constitues maybe 75% of my archiving,
  360. maybe more, the only cleaverness is how the original files are read and
  361. the disposition of any temporary files (i.e. is the program smart enuf
  362. to recognize i am ususally smart enuf to make $TEMP a ramdisk?). i think
  363. the fact that your equally limited tests, tho perhaps more realistic for
  364. your particular use, shows little difference implies that as far as IO
  365. is concerned, both are about as smart (or dumb). i suspect smart because
  366. i know of at least one tiny modification (which bill shroka did in fact
  367. do) which improves zoo's performance. i have not had a chance to examine
  368. lharc, tho i suspect it handles things pretty much the same.
  369.  
  370. >As devices get faster, I/O importance lessens.
  371.  
  372. another important point which can be broadened futher: as cpu's get faster,
  373. archiver tuning lessens in importance. as disks and communications get cheaper
  374. and faster, compression ratio lessens in importance.
  375.  
  376. >BTW: A better test would be to setup partitions of various sizes and fragmen-
  377. >tation on several different devices and then do the tests again
  378. >(just in theory, who's got the time..) - and - Just because a result is repro-
  379. >ducable, doesn't make it automatically the most meaningful result.
  380.  
  381. yes, but it DOES make it reproducable, in itself desirable over something
  382. both non-meaningful and non-reproducable. one is subjective, the other
  383. objective. your definition of meaningful may not be meaningful to someone
  384. else. and even if it were, if it could not be reproduced, it would resort
  385. to hearsay.
  386.  
  387. there are ALWAYS better tests. i think mine was fair for what i did. i tried
  388. to point out some of the weaknesses in the test that i saw. and i think that
  389. there can be no question that it is valid if all your archiving is done in
  390. ramdisk. except that i did not necessarily use "calibrated" files. i did,
  391. however, give a source for the files at least in one of the tests (portions
  392. of the MiNT distribution) so it could be reproduced.
  393.  
  394. >   Nat! (using ZOO [with 'h'] more often nowadays)
  395.  
  396. EXCELLENT!!!!
  397.  
  398. ciao
  399.  
  400. -bill
  401. --
  402. Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
  403. Convex Computer Corp.      |ARPA: rosenkra@convex.com
  404.  
  405. ------------------------------
  406.  
  407. Date: 3 Oct 91 21:40:06 GMT
  408. From:
  409.  europa.asd.contel.com!darwin.sura.net!haven.umd.edu!uflorida!mailer.cc.fsu.edu!
  410.  open!boyd@uunet.uu.net (Mickey Boyd)
  411. Subject: Mega2 questions
  412. To: Info-Atari16@naucse.cse.nau.edu
  413.  
  414. In article <kemionINN4ub@matt.ksu.ksu.edu>, kenneth@matt.ksu.ksu.edu (Kenneth W
  415.  Samson) writes:
  416. >I have three questions for those outthere that have Mega2s...
  417. >
  418. >2) I know that Mega2 will go to 4 meg of memory, but will it
  419. >   go all the way to 16 with standard simms on the motherboard?
  420. >
  421.  
  422. This is not true.  Some Mega2's have the traces and sockets for more memory
  423. (none of them use SIMMS, by the way).  Some have the traces, but no
  424. sockets.  The newer ones not only have no traces or sockets, but they have
  425. an MMU that only allows for 2mb.  You can upgrade any Mega2 with a third-
  426. party board, but you may need a new MMU also (they are not all that expensive).
  427. Four megabytes is all the Mega's can handle unless you do strange things
  428. (which would undoubtedly cause a lot of software to bomb).  Dave small reports
  429. that he has a 16meg 1040 for Spectre testing purposes.
  430.  
  431. Also, I read once that there are a select few Mega2's out there that have
  432. 4 megs in them, but are jumpered (or trace-cut) to only access 2megs.  The
  433. reason for this (reputedly) is that if a Mega4 fails quality control, they
  434. jump/cut it and test it as a Mega2.  If it works, it gets packed up and
  435. sold.  One poster to this group (about two years ago, I seem to remember)
  436. was shocked to find this out.  After tracing down the bad chip, he replaced it
  437. and un-jump/cut the motherboard to get a Mega4.  Ahh, the stuff dreams are
  438. made of . . .
  439. --
  440.     ---------------------------------+-------------------------------------
  441.              Mickey R. Boyd          |  "Come to your senses professor
  442.           FSU Computer Science       |     Fernberg.  You did not transcend
  443.         Technical Support Group      |     the time-space continuum.  You
  444.        email:  boyd@nu.cs.fsu.edu    |     got drunk in a topless bar."
  445.     ---------------------------------+-------------------------------------
  446.  
  447. ------------------------------
  448.  
  449. Date: 3 Oct 91 21:09:31 GMT
  450. From:
  451.  arizona.edu!cerritos.edu!orion.oac.uci.edu!usc!zaphod.mps.ohio-state.edu!unix.c
  452.  is.pitt.edu!dsinc!netnews.upenn.edu!eniac.seas.upenn.edu!efaskha@arizona.edu
  453.  (Eli Faskha)
  454. Subject: Questions on PC-Speed
  455. To: Info-Atari16@naucse.cse.nau.edu
  456.  
  457. Help. I've had a PC-Speed for some time, but haven't really taken full
  458. advantage of it. I know it can recognize the Atari ST mouse as a Microsoft
  459. Mouse, but I can't get it to do it...
  460.  
  461. Also, what's the latest revision of the software? I have revision 1.3, and
  462. I think there might be a new one out.
  463.  
  464. Where can I get in touch with Talon Technologies? Anyone know a net address
  465. or phone number?
  466.  
  467. Thanks,
  468.         Eli
  469.  
  470. ------------------------------
  471.  
  472. Date: 3 Oct 91 02:05:23 GMT
  473. From:
  474.  noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-st
  475.  ate.edu!linac!unixhub!ditka!slacvm!reeves@arizona.edu (Terry Reeves)
  476. Subject: SIM CITY - STe Compatible????
  477. To: Info-Atari16@naucse.cse.nau.edu
  478.  
  479. Sim City runs just fine on my STE, a 4meg 520 STE. The TOS version is 1.62.
  480.  
  481.                                                          Terry
  482.  
  483. Disclaimer: The above opinions are my own, and mine alone.
  484.  
  485. ------------------------------
  486.  
  487. Date: 3 Oct 91 03:29:46 GMT
  488. From:
  489.  noao!asuvax!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!
  490.  udecc.engr.udayton.edu!blackbird.afit.af.mil!lonex.rl.af.mil!longj@arizona.edu
  491.  (Jeffrey K. Long)
  492. Subject: SST for 1040STe's ??
  493. To: Info-Atari16@naucse.cse.nau.edu
  494.  
  495. Can anyone tell me if Dave Small will make a version of the
  496. SST that will work with 1040STe's??  I remember reading something about
  497. it several months ago, something to the effect that if STe sales
  498. warranted, then an adaptor to connect to the square 68000 in STe's.
  499.  
  500. I sure hope the answer is yes!  I am about ready to upgrade somehow, and
  501. the thought of being able to get an '030 box that might be able to run
  502. UNIX and still have my beloved atari stuff close at hand is
  503. intoxicating!!
  504.  
  505. If yes, when and about how much will such a beast set me back?
  506.  
  507. Jeff
  508. --
  509. ----------------------------------------------------------------------------
  510. Capt Jeff Long                         Rome Laboratories, Griffiss AFB, NY
  511. longj@lonex.rl.af.mil (preferred)      Network Design Laboratory
  512. jlong@cassiopeia.rl.af.mil             (315)330-7751 or (DSN)587-7751
  513.  
  514. ------------------------------
  515.  
  516. Date: 2 Oct 91 12:39:08 GMT
  517. From: aahs.no!data3d@ucbvax.berkeley.edu (Karl Anders 0ygard)
  518. Subject: STE simms
  519. To: Info-Atari16@naucse.cse.nau.edu
  520.  
  521. [Wayne Martinez writes]
  522. >Can I just go out and purchase some simms, crack the case,
  523. >and plug them in?
  524.  
  525. Obviously. At present I've got 4 9-bits 70ns 1Mb simms installed in my STe,
  526. giving me a total of 4megs. I got the simms 9-bits (8-bits will pass, I think)
  527. and 70ns (100ns should be enuf?) so that I'd be able to use them on a PC or a
  528. Mac, should I decide to do so.
  529.  
  530. Mind you, all of this may be wrong. Correct me if it is. ;)
  531.  
  532. Karl Anders Oygard - Karl A Oygard <data3d@aahs.no>
  533.  
  534. ------------------------------
  535.  
  536. Date: 2 Oct 91 23:25:45 GMT
  537. From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
  538. Subject: Using gcc/g++ to cross compile for the ST
  539. To: Info-Atari16@naucse.cse.nau.edu
  540.  
  541. >I'd like Unix zoo 2.1 source too, been too lazy to go looking myself.
  542.  
  543. atari.archive.umich.edu:atari/archivers/zoo21src.* (forgot if zoo or
  544. arc).
  545.  
  546. >I'm a little hazy on the MiNT support in the current version of gcc.
  547. >It causes the mint libraries to be loaded before the regular libraries,
  548. >but the mint library docs say "use this instead of the regular gnu
  549. >libraries." Some agreement/clarification would be nice.
  550.  
  551. sure, howard:
  552.  
  553. it took me a couple of tries myself. however, is is not too bad.
  554. i think the makefile in the t100 terminal emulator i recently posted
  555. has this. let's see if i can remember (for GCC 1.40, gmake 3.60, mint
  556. lib PL 10, i think - gmake contains some of my own hacks to get it to
  557. work for me):
  558.  
  559. # makefile from t100 (compiled for mint)
  560. CC              = gcc
  561. OPT             = -O
  562. # -v=verbose, -Wall=all warnings, -z=errs to compile.err, -I->mint *.h
  563. CFLAGS          = -v -Wall -z -Ig:/mint/include $(OPT)
  564. # -nostdlib is the key. also explicit crt0.o
  565. LDSPECIAL       = -nostdlib g:/mint/lib/crt0.o
  566. # -L->mint *.olb
  567. LDFLAGS         = -v -Wall -z -Lg:/mint/lib $(LDSPECIAL)
  568. # both gnu.olb and iio.olb must be specified as a byproduct of -nostdlib
  569. LIBS32          = -lgnu -liio
  570. LIBS16          = -lgnu16 -liio16
  571. # if -mshort, use LIBS16...
  572. LIBS            = $(LIBS32)
  573.  
  574. TARGET          = (your .ttp file here...)
  575.  
  576. OBJS            = (your program .o files here...)
  577.  
  578. $(TARGET):      $(OBJS)
  579.                 $(CC) $(LDFLAGS) -o $(TARGET) $(OBJS) $(LIBS)
  580.  
  581. there is probably a better way, but something along this lines should work.
  582. i keep "normal" gnu libraries and includes in g:/gcc/{lib,include}.
  583.  
  584. -bill
  585. rosenkra@convex.com
  586. long live GCC...
  587. --
  588. Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
  589. Convex Computer Corp.      |ARPA: rosenkra@convex.com
  590.  
  591. ------------------------------
  592.  
  593. Date: 3 Oct 91 20:06:40 GMT
  594. From:
  595.  noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!caen!spool
  596.  .mu.edu!cs.umn.edu!thelake!steve@arizona.edu (Steve Yelvington)
  597. Subject: ZOOSHELL 0.6
  598. To: Info-Atari16@naucse.cse.nau.edu
  599.  
  600. I recently shipped ZOOSHELL 0.6 off to atari.archive.umich.edu, and
  601. (naturally) a bug surfaced quite quickly. The bug is fairly obvious in the
  602. code, which also is available at a.a., so if you have Sozobon C and want
  603. to fix it, change the following in main():
  604.  
  605.         strcpy(zoottp,p);
  606.  
  607. to
  608.         if (p != NULL)
  609.                 strcpy(zoottp,p);
  610.  
  611. This bug surfaces only if ZOOSHELL can't find ZOO.TTP in the current
  612. directory or with a PATH search. If you use an environment-setting utility
  613. (which I wholeheartedly recommend for Desktop users) you'll never
  614. encounter this one.
  615.  
  616. I intend to release a newer version of ZOOSHELL, but at the moment I'm
  617. bogged down in the process of writing ARGV-compatible startup and
  618. process-control code so that ZOOSHELL can pass very long arguments to ZOO.
  619. (I also am doomed to work for a living, which interferes with recreational
  620. pursuits.)
  621.  
  622.  --
  623.  Steve Yelvington, Marine on St. Croix, Minnesota
  624.  steve@thelake.mn.org (In winter we walk on water)
  625.  
  626. ------------------------------
  627.  
  628. End of Info-Atari16 Digest
  629. ******************************
  630.